Zurück 
In den letzten anderthalb Jahren haben wir alle die enorme Umstellung erlebt, die sich daraus ergab, dass praktisch jeder von einem entfernten Standort aus arbeitete. Wir haben die VPN-Infrastruktur belastet und Split-Tunnel sind notgedrungen zur Regel und nicht zur Ausnahme geworden. Auch wenn dies bedeutete, dass die Benutzer etwas stärker exponiert waren, hatten Sie eigentlich keine andere Wahl, da Zoom-/Webex-/Teams-Meetings eine enorme Bandbreitenbelastung darstellen können.
Aber jetzt kehren die Benutzer wieder ins Büro zurück. Was ist daran so besonders? Wenn vor 18 Monaten alles einwandfrei funktioniert hat, sollte das doch ein Kinderspiel sein, oder?
Na ja, vielleicht. Ah, die klassische Antwort der Technologen: „Es kommt darauf an.“ Hier sind einige Dinge, die Sie hinsichtlich Ihres Netzwerks vielleicht noch nicht bedacht haben und die Sie berücksichtigen sollten, wenn die Benutzer wieder nach und nach ins Büro zurückkehren.
Haben Sie sichergestellt, dass alle Infrastrukturgeräte aktualisiert wurden?
Firewalls, Zugriffspunkte, IPS, IDS, Proxys und in geringerem Maße Router/Switches erfordern Wartung. Und Wartung bedeutet veränderte Steuerungen und Betriebsunterbrechungen. Legen Sie also jetzt los und stellen Sie sicher, dass alles aktualisiert und ordnungsgemäß neu gestartet wurde.
Haben Sie Änderungen am Netzwerk vorgenommen?
Neue oder geänderte Subnetze? Wenn Sie mit dem Gedanken spielten, das Routing-Protokoll zu ändern (beispielsweise von EIGRP zu BGP oder OSPF), dann ist jetzt der perfekte Zeitpunkt dafür. Vielleicht haben Sie noch Zeit, vom alten zum modernen Routingprotokoll zu wechseln. Aber hier ist ein Power-Tipp: Bevor Sie Änderungen an einem Remote-Router vornehmen, speichern Sie unbedingt die aktuelle Konfiguration und geben Sie „reload in 30“ ein, damit der Router zur Wiederherstellung in 30 Minuten neu gestartet wird. Es ist eine günstige Versicherung. Oh, und vergessen Sie nicht, anschließend auch „reload cancel“ einzugeben. Ich bin sicher, jetzt verstehen Sie, warum das Speichern der vorhandenen Konfiguration *SO* wichtig ist.
Wenn Sie neue Subnetze eingeführt oder vorhandenen eine neue IP zugewiesen haben, arbeiten Sie unbedingt mit Ihrem Proxy-Team zusammen, um die PAC-Datei zu aktualisieren. Im besten Fall sind Ihre Benutzer verärgert, im schlimmsten Fall funktionieren Ihre SaaS-/Cloud-Apps nicht. Dies ist besonders schlimm, wenn Ihre Helpdesk-App SaaS-basiert ist. Rekursives Routing kann schlecht sein, aber ein rekursiver Workflow kann wirklich zum Problem werden.
Haben Sie Ihr globales Adressbuch und Ihre Desktop-Windows-/Mac-Computer aktualisiert?
Sie denken vielleicht, dass Sie diesbezüglich abgesichert sind, weil alle Laptops verwaltet werden und somit über die aktuellsten Updates verfügen, nicht wahr? Aber was ist mit all den Desktop-PCs und Macs im Büro, die zum ersten Mal seit über einem Jahr wieder hochgefahren werden? In großen Unternehmen können globale Adressbücher mehrere Hundert MB groß sein. Stellen Sie sich vor, jeder Desktop lädt innerhalb der ersten Stunde nach dem Hochfahren eine über 100 MB große Datei herunter. Frag mich, woher ich das weiß! Und die PC-Updates? Wie wir in New York City sagen: Vergiss es! Wenn Sie über WakeOn-LAN-PCs verfügen, wäre jetzt ein guter Zeitpunkt, Ihr Helpdesk-Team zu bitten, diese PCs einzuschalten.
Und schließlich: Welche Rolle spielt das menschliche Verhalten?
Viele Ihrer Benutzer verfügen zu Hause über (sehr) schnelles Internet und haben sich an diese Geschwindigkeit für SaaS/Cloud und das Internet im Allgemeinen gewöhnt. Ich bin sicher, dass Ihre Internetverbindung ein gemeinsam genutzter Dienst ist. Informieren Sie Ihren Helpdesk daher, dass er möglicherweise mit einer Flut von E-Mails und Anrufen wegen „das Netzwerk ist langsam“ konfrontiert wird. Verfügen Sie vor diesem Hintergrund über eine gute Strategie zur Triage? Und hier ist eine überraschende Antwort: Geschwindigkeitstest-Apps SIND NICHT IHRE ANTWORT. Diese Apps belasten das Netzwerk, um die maximal verfügbare Bandbreite zu ermitteln, tragen jedoch nicht dazu bei, Benutzer mit einem schlechten Interneterlebnis zu identifizieren. Suchen Sie stattdessen nach einer Möglichkeit, INNERHALB Ihres Netzwerks einen Stresstest durchzuführen. Idealerweise eine Website oder sogar eine lizenzierte Geschwindigkeitstest-Infrastruktur, die Sie vor Ort betreiben. Oder stellen Sie zumindest sicher, dass Ihre Proxys automatisierte Tests durchführen. Dadurch wird das interne Netzwerk als Problem ausgeschlossen. Ich verwende gerne Google und Disney als zwei extreme Testfälle – von einer einfachen/leichten bis hin zu einer sehr inhaltslastigen Website. Stellen Sie abschließend sicher, dass Sie testen können, ob die Benutzer über Festnetz oder WLAN verbunden sind. Wenn Sie Chrome verwenden, enthält das Debug-Protokoll eine Fülle von Informationen, die Sie nutzen können.
Wenn Sie mehr von mir darüber erfahren möchten, was Sie vor der Rückkehr ins Büro beachten sollten, sehen Sie sich hier meine Folge des Tech Bytes-Podcasts an!
Den Blog lesen